repl: fix history truncation of long lines#15258
Conversation
0d5de78 to
1c092de
Compare
1c092de to
f7c0edf
Compare
30f1e1f to
2e03021
Compare
9999814 to
153ff2f
Compare
153ff2f to
1574820
Compare
4e74cdf to
bca37f6
Compare
3f8b0da to
79e4f2c
Compare
Editline's `read_history` uses `fgets(buf, 256, fp)` internally, splitting any line longer than 255 characters into multiple history entries. This commit bypasses it with `FdSource::readLine` and per-line `add_history` calls, which handle arbitrary lengths. GNU readline's `read_history` has no such limit and is left as-is, and `write_history` already writes full lines via `fprintf` so it needs no change either.
|
I don't thinkt the test is working. When I run the repl through I'm not entirely sure whats going on there.. but perhaps we are missing some other initialization code. The |
|
Meh, somebody forgor to call @Ericson2314, @amaanq please be more careful and at least run the code. I'm going to fix this mess, but I don't enjoy having to constantly clean up regressions. |
|
What's even the purpose of |
repl: fix history truncation of long lines
Motivation
Editline's
read_historyusesfgets(buf, 256, fp)internally, splittingany line longer than 255 characters into multiple history entries. This
commit bypasses it with
std::getlineandadd_historycalls, whichhandle arbitrary lengths. GNU readline's
read_historyhas no such limitand is left as-is, and
write_historyalready writes full lines viafprintfso it needs no change either.Context
nix replsplits long lines inrepl-history#15162Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.